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(57) Tlie invention relates generally to the manage- 
ment of distributed databases, and more particularly to 
a method and an arrangement associated with manag- 
ing database schemas and configuration of software 
that uses those schemas. The objective of this invention 
is to present a method and a system, which allows man- 
aging database schemas and application software in 
large distributed multi-database systems and avoiding 
problems that are related to the prior art systems. The 
objective of the invention is attained by using configura- 
tion manager apparatus (231), which is external to the 
configuration and databases being managed (200). The 



objective of the invention is preferably also attained by 
providing a mechanism for keeping multiple, possibly 
different database schemas and application software in 
synchronization. The external configuration manage- 
ment node (231) manages the configuration manage- 
ment replicas (203, 213, 223) in each part (201, 211, 
221) of the distributed database system (200). These 
synchronized configuration management replicas com- 
prise scripts that are used for creating and/or updating 
the schemas of the database nodes and configuration 
of software that uses these database nodes (202, 212, 
222) 
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Description 

[0001] The invention relates generally to the manage- 
nnent of distributed databases, and nnore particularly to 
a method and an arrangennent associated with manag- 
ing database schemas. 

[0002] The following notions are used in this applica- 
tion: 

"Data management system" is an entity, which com- 
prises one or more databases and/or data manage- 
ment systems, whereby the system is responsible 
for reading the data structures contained in the da- 
tabases and/or data management systems and for 
changing these data structures. 

"Database" is an information structure, which com- 
prises one or more data elements, and the use of 
which is controlled by the data management sys- 
tem. The invention is applicable both in relational 
databases and in databases of other fonris, such 
as in object-oriented databases. 

"Data element" is an information structure, which 
can comprise other data elements or such data el- 
ements, which can be construed as atomary data 
elements. For instance, in a relational database da- 
ta elements are represented by tables comprising 
rows. The rows comprise fields, which are typically 
atomary data elements. 

"Database operation" is an event, during which data 
elements are read from the database, during which 
data elements of the database are modified, during 
which data elements are removed from the data- 
base, and/or during which data elements are added 
to the database. 

"Transaction" is a plurality of database operations 
acting on the data elements. A transaction can also 
comprise further transactions. 

"Database Schema" is the structure of a database 
system, described in a formal language supported 
by the database management system (DBMS). In 
a relational database, the schema defines the ta- 
bles, the fields in each table, and the relationships 
between fields and tables. 

"Database Catalogue" logically partitions a data- 
base so that data is organized in ways that meet 
business or application requirements. Each logical 
database is a catalogue and contains a complete, 
independent group of database objects, such as ta- 
bles, indexes, procedures and triggers. Each of 
these catalogues can act as a master or replica da- 
tabase. This makes it possible, for example, to cre- 
ate two or more replica databases into one physical 



database. It is also possible to have one or more 
catalogues in this same local database that repre- 
sent master database(s). 

5 "Database Node" is a database catalogue, which 
has been defined to act as a master or replica and 
thus participates in a hierarchy of synchronized da- 
tabases. 

10 "Master database" is a database catalogue in a da- 
tabase synchronization system that contains the of- 
ficial version of synchronized/distributed data. A 
master database can have multiple replica databas- 
es. 

15 

"Replica database" is a database catalogue in a da- 
tabase synchronization system that contains a full 
or partial tentative copy of the master data. 

20 "Publication" is a set of data in a database cata- 
logue that has been published in master database 
for synchronization to one or multiple replica data- 
bases. 

25 "Synchronization" is operation between replica and 
master database catalogues in which changed data 
is exchanged between the catalogues. In one 
known embodiment, this means propagation of In- 
telligent transactions from replica to master and 
30 subscribing to a publication to download changed 
data from master to replica, [1] EP 0 860 788. 

"Schema revision" is a snapshot version of a sche- 
ma that is identifiable by logical name or version 
35 number. 

"Schema script" is a script that creates a schema or 
creates a new revision of an existing schema of a 
database node. 

40 

"Schema subscript" is a schema script that is exe- 
cuted from another schema script. 

"Schema script publication" is a system publication 
45 that contains the schema scripts of the database hi- 
erarchy. 

[0003] A schema is a representation of the structure 

of the database that illustrates what kind of data is stored 
50 in the database. In distributed database management 
environments, it must be possible to distribute new 
schemas as well as modify the existing schemas of the 
databases of the system in a flexible and controllable 
manner. 

55 [0004] Figure 1 illustrates an example of prior art da- 
tabase arrangement 100. The database system in- 
cludes a server 1 01 with an application master database 
1 02. This application master database includes a sche- 



25 



30 



3 



3 



EP 1 256 889 A2 



4 



ma master of the data stored in the database. The da- 
tabase system also includes two servers 111 and 121 
with application replica databases 112, 122. The appli- 
cation replica databases can maintain a full or partial 
copy (replica) of the application master database serv- 
ers' data using suitable data synchronization technolo- 
gy, such as functionality disciosed in patent application 
document [1] EP 0 860 788. The application replica da- 
tabases include schemas 113, 1 23, which may be a full 
or partial copy of the schema 103 of the application mas- 
ter database. Some prior art solutions for managing 
schemas in distributed database systems are described 
in documents [2] US 5 806 066, [3] WO 00/45286 and 
[4] WO 00/04445. 

[0005] In the prior art implementations schema up- 
grades are made in the master and these upgrades are 
distributed to the replicas transparently using some 
hard-coded rules. This approach introduces some prob- 
lems that make operating large multi-database systems 
difficult: 

There is no possibility in prior art implementations 
to control the schema upgrade process program- 
matically. For instance, sometimes the nature of a 
schema modification operation require that servic- 
es for all on-line users of the database are discon- 
nected while the schema is being upgraded. This 
requires programmatic control over the upgrade 
process in replica databases. 

There is no overall view about the upgrade status 
of different databases of the system. Failed up- 
grades are not reported anywhere and the system 
operator does not necessarily know, which replicas 
have upgraded to new revision and which have not 
yet done so. 

If the automatic upgrade fails, there is no possibility 
for error handling and system recovery. There is nei- 
ther a possibility to prevent such errors. Typically 
the replica database must be recreated from 
scratch in this kind of situation. 

Upgrading a system where different replicas can 
have different schemas and where replicas can 
have local tables that are not defined in the master 
is a difficult task. 

The prior art technology does not support outsourc- 
ing the runtime configuration control of distributed 
systems to third parties. 

[0006] For these reasons, the database schemas of 
prior art distributed systems are typically not well man- 
ageable. 

[0007] The objective of this invention is to present a 
method and an arrangement, which allows managing 
database schemas and related application software 



configuration in large distributed multi-database sys- 
tems and avoiding said problems that are related to the 
prior art systems. 

[0008] The objective of the invention is attained by us- 

5 ing a schema and software configuration manager ap- 
paratus, which is external to the database nodes and 
software being managed. This configuration manager 
apparatus is here referred to as "schema and software 
configuration management node". The objective of the 

10 invention is preferably also attained by providing a 
mechanism for keeping multiple, possibly different da- 
tabase schemas and their applications in synchroniza- 
tion. The external configuration management node 
manages the schema and software configuration man- 

15 agement replicas in each server of the distributed data- 
base system. These synchronized schema/application 
configuration management replicas comprise scripts 
that are used for creating and/or updating the schemas 
of the database nodes and managing the configurations 

20 of applications that use the database node. The inven- 
tion thus provides a solution to the problem of managing 
schemas of distributed databases and applications that 
use those databases. 

[0009] The database schema and application config- 
25 uration management database node is typically a sep- 
arate database node that can reside in a database serv- 
er same as or different from the application database 
server. If the hierarchies of application database nodes 
and management database nodes are identical, the 
30 management database node can be made a part of the 
application database node. 

[001 0] One idea of the invention is to utilize relational 
data synchronization mechanism along with application 
logic to manage schemas of potentially large number of 
35 application database nodes. This allows building large 
distributed systems with separate but still closely inte- 
grated configuration control functionality. 
[0011] Inventive features in some embodiments ac- 
cording to the invention are: 

40 

Extracting the schema management mechanism 
from the application's schema to an independent 
entity, 

45 - IVIanaging all or some of the different schemas and 
applications of a distributed system in one location, 

Utilizing incremental synchronization mechanism 
for distributing the new and modified schema and 
50 software configuration scripts to the nodes of the 
system, and 

Utilizing a revision name for detecting the need for 
schema and application configuration data syn- 
55 chronization, i.e. the schema is upgraded if its revi- 
sion property does not match with master's respec- 
tive property. 
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[0012] The "schema management" means here that 
database objects such as tables, indices, procedures, 
triggers etc. are amended, added or deleted. The "ap- 
plication configuration management" means here that 
application software and/or its configuration parame- 
ters, security material such as keys and certificates as 
well as other data and software needed to run the ap- 
plication, are amended, added or deleted. It also means 
here the management of software and data that is used 
for verifying consistency and validity of application pro- 
grams and applications' data of the system. 
[0013] A database system may include server com- 
puters, smart terminals, other terminals and network 
nodes. A network node may be e.g. a base station con- 
troller, access router, optical network router, radio net- 
work controller (RNC) controlling a base station control- 
ler (BSC), etc. These parts of the distributed database 
system may have a wireless or wireline connection to 
the other parts of the system. If a network-based server 
is used, the application can, in some embodiments, be 
located and invoked by using the Uniform Resource Lo- 
cator (URL) of the server. The schema/application con- 
figuration management node may also be a server, a 
client terminal or other node mentioned above, with a 
wireless or wireline connection to the other servers and 
terminals, which include parts of the distributed data- 
base. The database may be Oracle, Solid, Times Ten, 
Polyhedra, Clustra or any other database. 
[001 4] With the present invention it is thus possible to 
remotely manage schemas of distributed databases 
stored in terminals and various servers and keep the 
schemas and applications that use the schemas auto- 
matically in synchronization. The present invention has 
several advantages over the prior art solutions: 

It is possible to manage the runtime configuration 
control of distributed systems externally and there- 
fore outsourced services of third parties can be 
used for providing this function. 

It is possible to control the schema and application 
configuration upgrade process programmatically. 
For instance, sometimes the nature of a schema 
modification operation require that services for all 
on-line users of the database are disconnected 
while the schema is being upgraded. This requires 
programmatic control over the upgrade process in 
replica database nodes. 

It is possible to have an overall view about the up- 
grade status of different database nodes of the sys- 
tem. Failed upgrades can be reported or prevented, 
and the system operator has the information, which 
replicas and masters have upgraded to new revi- 
sion and which have not yet done so. 

If the automatic upgrade fails, there is a possibility 
for error handling and system recovery. There is al- 



so a better possibility to prevent such errors, be- 
cause the control of the schemas of the database 
system is centralized. It is possible to prevent situ- 
ations where it is necessary to recreate replica da- 
5 tabase from scratch. 

It is also possible to upgrade a system where differ- 
ent replicas can have different schemas and where 
replicas can have local tables or local private data 
10 in any shared table that are not defined or managed 
in the master. 

[0015] Further, together with updating schemas of a 
database system, it is also possible to update other in- 
15 formation of a node using the same updating route and 
procedures. This may include, for example, updating 
configuration scripts, updating configuration programs 
and changing application binaries into a new version 
level. Schema scripts can also include DML (Data Ma- 
20 nipulation Language) or DDL (Data Definition Lan- 
guage) scripts, or any other data manipulation scripts. 
In some embodiments this is used to set up version in- 
formation for applications to detect the need for update. 
[0016] The method according to the invention for 
25 managing schemas and/or application configuration in 
at least one database system comprising at least one 
application master database and at least one applica- 
tion replica database, wherein at least one of said data- 
bases comprises a schema of the data stored in the da- 
30 tabase, is characterized in that the at least one schema 
and/or application configuration is managed externally 
of said at least one application master database and at 
least one application replica database. 
[0017] The invention also relates to a storage media 
35 comprising a stored, readable computer program, which 
is characterized in that the program comprises instruc- 
tions for controlling a data management system or com- 
ponents thereof to implement the method according to 
the invention. 

40 [001 8] The invention further relates to a configuration 
management arrangement for at least one database 
system comprising at least one server with application 
master database and at least one server with application 
replica database, wherein at least one database com- 
^5 prises a schema of the data stored in the database, 
which is characterized in that the arrangement compris- 
es a configuration management node for managing a 
database schema and/or application configuration of 
said at least one database server, wherein said config- 
50 uration management node is separate from said at least 
one application master database. 
[001 9] The invention further relates to a configuration 
management node for at least one database system, 
comprising means creating and/or updating schemas 
55 and/or application configuration of a database system 
comprising at least one database in at least one data- 
base server, wherein the configuration management 
node is external of said at least one database server. 
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[0020] The best mode of the invention is considered 
to be a separate updating of replica schema from the 
master schema. 

[0021] Some embodiments of the invention are de- 
scribed in the dependent claims. 
[0022] Next the invention is described In more detail 
with reference to embodiments shown as examples and 
to the enclosed figures, in which: 

Figure 1 illustrates a distributed database system 
according to the prior art, 

Figure 2a illustrates the basic units of an exemplary 
configuration management system ac- 
cording to the invention , wherein the appli- 
cation database hierarchy is different from 
the schema and application configuration 
management database hierarchy, 

Figure 2b illustrates the basic units of an exemplary 

configuration management system ac- 
cording to the invention , wherein the appli- 
cation database hierarchy is the same as 
the schema and application configuration 
management database hierarchy 

Figures illustrates a flow diagram of exemplary 
steps setting up master database accord- 
ing to the invention; 

Figure 4 illustrates a flow diagram of exemplary 
steps for setting up and registering replica 
database and installing application soft- 
ware according to the invention; 

Figures illustrates a flow diagram of exemplary 
steps for upgrading the master database 
schema and application configuration ac- 
cording to the invention; 

Figure 6 illustrates a flow diagram of exemplary 
steps for upgrading the replica database 
schema and application configuration ac- 
cording to the invention; 

Figure 7 illustrates a flow diagram of exemplary 
steps according to the invention for up- 
grading the master database schema and 
application configuration after a replica da- 
tabase schema has changed; 

Figure 8 illustrates an exemplary system environ- 
ment where the invention can be applied; 
and 

Figure 9 illustrates a hierarchic system for manag- 
ing database schemas and application 
configurations. 



[0023] Figure 1 was described in the prior art descrip- 
tion above. Figure 2a shows an example of an arrange- 
ment according to the invention in a case where the ap- 
plication database hierarchy is different from the sche- 

5 ma and application configuration management data- 
base hierarchy. The arrangement comprises three main 
components; application master database server 201 , 
application replica database servers 211, 221, and 
schema management node 231 . Application master da- 

10 tabase node 202 and replica database nodes 212, 222 
form a distributed system, wherein the application rep- 
lica database nodes can maintain a full or partial copy 
(replica) of the application master database servers' da- 
ta using suitable data synchronization technology, such 

15 as functionality disclosed in patent application docu- 
ment [1] EP 0 860 788. The arrow lines between the 
blocks mean synchronization relationship between the 
database servers. 

[0024] The database schemas are managed by the 
20 configuration management node 231 . The configuration 
management node 231 includes a configuration man- 
agement application 234for managing the schemas and 
application configuration of the database system. There 
is also a configuration management master 233 stored 
25 in the configuration management node, and replicas 
203 213, 223 of the configuration management master 
are stored into database servers 201, 211, 221 of the 
database system. It is also possible that some applica- 
tion database server does not have a schema manage- 
30 ment replica if the configuration management data is re- 
liably and quickly available from some other node, such 
as configuration management master of the network. 
[0025] The configuration management replicas may 
be full or partial copies of the configuration management 
35 master 233. The configuration management replicas in- 
clude scripts for creating and/or updating the schemas 
and/or application configuration of the databases. The 
updating between the configuration management mas- 
ter and the configuration management replicas can be 
40 made using the synchronization functionality of the serv- 
ers [1]. Other methods may include direct transfer of 
schema's managed data from master to replica, or any 
other methods of information exchange. 
[0026] Figure 2b shows an example of an arrange- 
45 ment according to the invention in a case where the ap- 
plication database hierarchy is the same as the schema 
and application configuration management database hi- 
erarchy. When the database hierarchies are identical, i. 
e. both application replica and configuration manage- 
50 ment replica synchronize their data from the same mas- 
ter node, the application and configuration management 
replicas can be implemented as one replica node. 
[0027] In the following exemplary methods for remote 
configuration management according to the invention 
55 are described in more detail referring to Figures 3-7. 
[0028] Figure 3 illustrates a method for setting up 
master database. In step 302 the database schema is 
defined using configuration management application 
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and stored to the schema management master data- 
base, step 303. If the application database hierarchy is 
different from configuration database hierarchy, two 
new, empty logical database nodes are created to the 
database server where the application master database 
will reside, step 304. If the hierarchies are identical, 
these two nodes can be combined into one. In step 306 
one of the empty database nodes is dedicated to be the 
replica node of the configuration management master 
database and registered with the master. As part of the 
registration, the identification data, e.g. schema name, 
of the new application database node is sent to the con- 
figuration management master database node. The 
newly created configuration management replica is then 
synchronized with its master database in step 30B. This 
downloads the schema creation scripts and possibly al- 
so application configuration data such as software bina- 
ries and installation programs of the application master 
to the database server. Next the schema of the applica- 
tion master database node is created using the scripts 
that were downloaded to the new replica database 
node, 31 0. Atthis phase, also the software configuration 
data can be extracted from the database and installed, 
312. Now the master database node along with the ap- 
plication is ready for use. 

[0029] Figure 4 illustrates a method for setting up and 
registering replica database. First in step 402 the data- 
base schema and application configuration of the repli- 
ca database node is defined in using the configuration 
management application and stored, 403, to the config- 
uration management master database node. This step 
is typically made at the same time when the configura- 
tion of the application's master database schema and 
applications are defined. 

[0030] In step 404 two new, empty database nodes 
are created to the database server where the application 
replica database will reside. One of the new empty da- 
tabases of this server is dedicated to be the replica node 
of the configuration management master database and 
registered with the configuration management master, 
step 406. As part of the registration, the identification 
data, e.g. schema name of the new application data- 
base is sent to the configuration management master 
database node. Next in step 408 the newly created con- 
figuration management replica is synchronized with its 
master database, This downloads the schema creation 
scripts of the replica and possibly also application con- 
figuration data and software to the database node. In 
step 409 the application replica database node registers 
itself with the application master database using regis- 
tration scripts found from the schema management rep- 
lica of the server. The schema of the application replica 
database node is created using the scripts that were 
downloaded to the configuration management replica 
database node, 41 0. Finally, the replica application soft- 
ware is installed, 412. If the database hierarchies are 
identical, i.e. both application replica and configuration 
management replica synchronize their data from the 



same master node, the application and configuration 
management replicas can be implemented as one rep- 
lica node. 

[0031] Figure 5 illustrates a method for upgrading the 

5 master database schema. First in step 502 a set of 
scripts is created for a new revision of the master data- 
base schema in the configuration management applica- 
tion, and stored to the configuration management mas- 
ter, 503. In step 504 the configuration management rep- 

10 lica database node of the application master server sub- 
scribes the data of the new revision from the configura- 
tion management master by synchronizing itself with the 
master database node. The application master schema 
is updated by running the scripts of the new revision, 

15 506. The scripts are found from the configuration man- 
agement replica database of the server. After this, the 
application configuration can be upgraded by using the 
application configuration data and software that was 
downloaded during thesynchronization, 507. During the 

20 execution of the scripts, log entries can be stored to a 
table of the configuration management replica. After 
successful execution of the scripts, the revision level of 
the application master schema is upgraded. Next in step 
508 the log entries written in step 506 are propagated 

25 to the configuration management master by synchroniz- 
ing the configuration management replica database 
node. The system administrator can review the success 
of the upgrade by viewing the log entries using the con- 
figuration management application, 510. 

30 [0032] Figure 6 illustrates a method for upgrading the 
replica database schema and/or application configura- 
tion after the master database schema and/or applica- 
tion configuration has been upgraded according to Fig. 
5. First in step 602 a set of a new revision (that matches 

35 with the earlier created master revision) of the applica- 
tion replica database schema is created in the configu- 
ration management application and stored, 603, to the 
configuration management master. The application rep- 
lica tries to synchronize with the application master da- 

40 tabase node in step 604, but fails because the schema 
of the application master database node has been up- 
graded to a new revision level. Alternatively, configura- 
tion management node can infomn the application rep- 
lica database about the need to upgrade the schema. 

^5 The configuration management replica database of the 
application replica server subscribes the upgrade 
scripts of the new schema and application configuration 
revision from the configuration management master by 
synchronizing itself with the master database node, step 

50 605. 

[0033] Next in step 606 the application replica sche- 
ma is updated by running the scripts of the new revision. 
The scripts are found from the configuration manage- 
ment replica database of the server. After this, the ap- 
55 plication configuration can be upgraded by using the ap- 
plication configuration data and software that was down- 
loaded during the synchronization, 607. During the ex- 
ecution of the scripts, log entries can be stored to a table 
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of the configuration management replica. After success- 
ful execution of tlie scripts, the revision level of the ap- 
plication replica schema is upgraded. The log entries 
written in step 606 are propagated to the schema man- 
agement master by synchronizing the configuration 
management replica database node, step 608. Nowthat 
the revision levels of the application master and the rep- 
lica databases are the same, the application replica da- 
tabase node can synchronize with the application mas- 
ter database node again, 609. The system administrator 
can review the success of the upgrade by viewing the 
log entries using the configuration management appli- 
cation, 61 0. 

[0034] Figure 7 illustrates a method for upgrading the 
master database schema after a replica database sche- 
ma has changed (a replica database schema can 
change similarly as shown in Fig. 5 for the master data- 
base schema). First in step 702 a set of a new revision 
(that matches with the earlier created replica revision) 
of the application master database schema is created 
in the configuration management application and 
stored, 703, to the configuration management master. 
The application replica tries to synchronize with the ap- 
plication master database in step 704, but fails because 
the schema of the application replica database has been 
upgraded to a new revision level. The configuration 
management replica database node of the application 
master server subscribes the upgrade scripts of the new 
revision from the configuration management master by 
synchronizing itself with the master database node, step 
705, 

[0035] Next in step 706 the application master sche- 
ma and possibly also application configuration is updat- 
ed by running the scripts of the new revision. The scripts 
are found from the configuration management replica 
database of the server. During the execution of the 
scripts, log entries can be stored to a table of the con- 
figuration management replica. After successful execu- 
tion of the scripts, the revision level of the application 
master schema is upgraded. The log entries written in 
step 706 are propagated to the configuration manage- 
ment master by synchronizing the configuration man- 
agement replica database node, step 708. Now that the 
revision levels of the application master and the replica 
database nodes are the same, the application replica 
database can synchronize with the application master 
database node again, 709. The system administrator 
can review the success of the upgrade by viewing the 
log entries using the configuration management appli- 
cation, 710. 

[0036] Figure 8 illustrates an example of an equip- 
ment environment where the present invention can be 
applied. The database system comprises the server for 
application master database node 801, and several 
servers for application replica database nodes. The ap- 
plication replica database servers include an online sta- 
tion 81 1 , to which a laptop terminal 841 and WAP termi- 
nal 851 are connected. There is also a data-warehouse 



including the application replica database node. A sep- 
arate configuration management node 831 manages 
configurations of all the database servers of the data- 
base system. The configuration management node 831 

5 has therefore individual synchronization connections to 
all blocks 801 , 811 , 821 , 841 and 851 . 
[0037] Figure 9 illustrates an example of a hierarchic 
system where several database systems a, b, c have 
their respective schema management nodes 931a, 

10 931b and 931c which manage the schemas of the re- 
spective database nodes. The database systems have 
a common configuration management node 931 for 
managing schemas and application configuration of all 
database systems a, b and c. The configuration man- 

15 agement nodes 931a, 931b and 931c of the individual 
database systems are thus replicas of the main config- 
uration management node 931. If the hierarchy of the 
application database is the same as the hierarchy of the 
configuration management databases, the manage- 

20 ment database may be included as part of the applica- 
tion database. 

[0038] A system according to the invention can be im- 
plemented by a person skilled in the art with state of the 
art information technology and communication technol- 
25 ogy components. A person skilled in the art can imple- 
ment the functions according to the invention by arrang- 
ing and programming such components to realize the 
inventive functions. 

[0039] For example, the invention can be implement- 
30 ed to work in a telecommunication system, which is 
complient with at least one of the following: TCP/IP, CD- 
MA, GSM, GPRS, WCDMA, UMTS, Teldesic, Iridium, 
Inmarsat, WLAN and imode. 

[0040] It is also possible to use a standardized oper- 
35 ating system in the terminals and servers. The operating 
system of a terminal can be, for example, Unix, MS-win- 
dows, EPOC, NT, MSCE, Linux, PalmOS and GEOS. 
The servers for application master database and sche- 
ma management application may preferably have at 
40 least one of the following operating systems: Unix, MS- 
windows, NT and Linux. 

[0041] To a person skilled in the art it is obvious that 
in order to have an illustrative description the above pre- 
sented exemplary embodiments have a structure and a 

45 function, which are relatively simple. By applying the 
model presented in this application it is possible to de- 
sign different and very complicated systems, which in 
obvious ways to the expert, utilise the inventive idea pre- 
sented in this application. 

50 [0042] One should note that, although embodiments 
concerning schema configuration management are de- 
scribed, the invention is also well applicable to applica- 
tion configuration management. 

55 
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Claims 

1. A method for managing database schemas and/or 
application configuration data in at least one data- 
base system comprising at least one application 
master database and at least one application repli- 
ca database, wherein at least one of said databases 
comprises a schema of the data stored in the data- 
base, characterized in that 

at least one schema and/or application config- 
uration is managed externally of said at least 
one application master database or at least one 
application replica database. 

2. A method according to claim 1 , characterized in 

that at least one configuration management master 
is provided in at least one configuration manage- 
ment node, which is separate from each of said da- 
tabase nodes, a replica of at least parts of said con- 
figuration management master is stored to a server 
comprising the at least one database, and the sche- 
ma of said at least one database is created and/or 
updated on the basis of scripts of said configuration 
management replica. 

3. A method according to claim 2, characterized in 
that the configuration of at least some databases 
of said database system are managed by said con- 
figuration management node. 

4. A method according to claim 2, characterized in 
that the application configuration of at least some 
applications of said database system are managed 
by said configuration management node. 

5. A method according to claim 2, characterized in 
that at least parts of said configuration manage- 
ment master and said parts of said configuration 



management replica are synchronized. 

6. A method according to claim 1, characterized in 
that at least parts of the application master data- 

5 base and said parts of the application replica data- 
base are synchronized. 

7. A method according to claim 1, characterized in 
that the data of configuration management master 

10 is maintained by a configuration management ap- 
plication of said configuration management node. 

8. A method according to claim 1, characterized in 
that the method is complient with at least one of the 

15 following communication specifications: TCP/IP, 
CDMA, GSM, GPRS, WCDMA, UMTS, Teldesic, 
Iridium, Inmarsat, WLAN and imode. 

9. A method according to claim 1, characterized in 
20 that at least one of the following operating systems 

is used in at least one terminal including an appli- 
cation replica database of the database system: 
Unix, MS-Windows, EPOC, NT, MSCE, Linux, Pal- 
mOS and GEOS. 

25 

10. A method according to claim 1, characterized in 
that at least one of the following operating systems 
is used in the at least one server including an appli- 
cation master database of the database system: 

30 Unix, MS-Windows, NT and Linux. 

11. A method according to claim 1, characterized in 
that the database is a database node residing in a 
database server. 

35 

12. A method according to claim 1, characterized in 
that schemas and/or application configuration of at 
least two database systems are managed by a com- 
mon configuration management node, wherein a 

40 configuration management node of an individual 
database system is a replica of said common con- 
figuration management node. 

13. A method according to claim 1, characterized in 

45 that the hierarchy of the application databases is 
the same as the hierarchy of the configuration man- 
agement databases, wherein the configuration 
management database is included as part of the ap- 
plication database. 

50 

14. A storage media comprising a stored, readable 
computer program, characterized in that the pro- 
gram comprises instructions for controlling a data- 
base system or components thereof to implement 

55 a method according to claim 1 . 

15. A configuration management arrangement for at 
least one database system comprising at least one 
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server with application master database and at 
least one server with application replica database, 
wherein at least one database comprises a schema 
of the data stored in the database, characterized 
in that the arrangement comprises a configuration 
management node for managing a database sche- 
ma of said at least one database server and/or con- 
figuration of applications accessing the database, 
wherein said configuration management node is 
separate from said at least one application master 
database. 

16. An arrangement according to claim 15, character- 
ized in that said configuration management node 
comprises a configuration management master, 
wherein the at least one application master data- 
base server and the at least one application replica 
database server comprise a replica of at least parts 
of said configuration management master, and the 
arrangement comprises means for creating and/or 
updating the schema and/or application configura- 
tion of said at least one database on the basis of 
scripts of said configuration management replica. 

17. An arrangement according to claim 15, character- 
ized in that some or all database servers of the da- 
tabase system comprise a replica of said configu- 
ration management master. 

18. An arrangement according to claim 15, character- 
ized in that the arrangement comprises means for 
synchronizing at least parts of said configuration 
management master and said parts of said config- 
uration management replica. 

19. An arrangement according to claim 15, character- 
ized in that the database system comprises means 
for synchronizing at least parts of the application 
master database and said parts of the application 
replica database. 

20. An arrangement according to claim 15, character- 
ized in that the configuration management node 

comprises a configuration management application 
for creating and/or updating the configuration man- 
agement master. 

21. An arrangement according to claim 15, character- 
ized in that the arrangement and/or the database 
system is compatible with at least one of the follow- 
ing communication specifications: TCP/IR CDMA, 
GSM, GPRS, WCDMA, UMTS, Teldesic, iridium, In- 
marsat, WLAN and imode. 

22. An arrangement according to claim 15, character- 
ized in that the application replica database is pro- 
vided in a terminal, which is a combination of a mo- 
bile station and a computer. 



23. An arrangement according to claim 22, character- 
ized in that the terminal has at least one of the fol- 
lowing operating systems: Unix, MS-windows, EP- 
OC, NT, MSCE, Linux, PalmOS and GEOS. 

5 

24. An arrangement according to claim 15, character- 
ized in that the application master database server 
and/or the configuration management node has at 
least one of the following operating systems: Unix, 

10 MS-Windows, NT and Linux. 

25. An arrangement according to claim 15, character- 
ized in that the database is a database node resid- 
ing in a database server. 

15 

26. An arrangement according to claim 15, character- 
ized in that it comprises a common configuration 
management node for managing schemas of at 
least two database systems, wherein a configura- 
te tion management node of an individual database 

system is a replica of said common schema man- 
agement node. 

27. An arrangement according to claim 15, character- 
25 ized in that the hierarchy of the application data- 
base is the same as the hierarchy of the configura- 
tion management database, wherein the manage- 
ment database is included as part of the application 
database. 

30 

28. An arrangement according to claim 15, character- 
ized in that the configuration management node is 
for managing a database schema of said at least 
one database server. 

35 

29. A configuration management node for at least one 
database system, the database system comprising 
at least one database in at least one database serv- 
er, wherein the configuration management node 

40 comprises means for creating and/or updating con- 
figuration of schemas and/or applications access- 
ing the database system, wherein the configuration 
management node is external of said at least one 
database. 

45 

30. A configuration management node according to 
claim 29, characterized in that it comprises means 
for providing a configuration management master 
and a configuration management application for 

50 providing a database of the database system a rep- 
lica of the configuration management master. 

31. A configuration management node according to 
claim 29, characterized in that it comprises means 

55 for synchronizing said configuration management 
replicas of the database system with said configu- 
ration management master. 
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32. A configuration nnanagement node according to 
claim 29, characterized in that said configuration 

management master and/or configuration manage- 
ment replica comprises scripts for creating and/or 
updating tlie schema of the at least one database 5 
and/or configuration of application accessing the 
database. 

33. A configuration management node according to 
claim 29, characterized in that it is a replica of a io 

common configuration management node for man- 
aging at least two database systems, 

34. A configuration management node according to 
claim 29, characterized in that the configuration is 

management node is for managing a database 
schema of said at least one database server. 
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